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NASA ACCOUNTING AND FINANCIAL 
INFORMATION SYSTEM (NAFIS): 

A CRITICAL ASSESSMENT OF THE SYSTEMS 
DEVELOPMENT METHODOLOGY 

In partial fulfillment of my Summer Faculty Fellowship contractual obligation, Mr. Alan Forney 
instructed me to examine the NAFIS systems development methodology and make recommendations to 
improve the process. The following comments represent a summary of my recommendations: 

1. Recognize that system success is more of a function of good managerial practices than good technology 
and/or good coding. 

2. Develop a systematic method of dealing with changes in requirements during the life cycle. Each 
document should outline how changes will be made during development and after implementation. 

3. Clearly establish if NAFIS is a management information system (MIS) or an accounting and financial 
system. This must be conveyed to site managers and users early in the process since heightened expectations 
by users can be deadly to the perceived success of the project. 

4. Undertake Independent Verification & Validation (IV&V) early in the life cycle. This could be 
problematic since the SRS’s could be completed before an IV&V contractor is under contract. Since many 
of the errors occur early in the life cycle, the IV&V activity will be less effective. 

5. Charge the IV&V contractor with providing periodic estimation of project costs and progress as they 
relate to the NAFIS plan. New estimates should be developed whenever specifications change. 

6. Maintain file of potential operational and managerial problems throughout the development life cycle. 

7. Develop metrics for system success. Document delivery must not serve as a metric for system success. 

8. Undertake prototyping to insure that systems requirements established by upper level management satisfy 
those who actually use the system. This is an important task since it provides the user with a tangible product 
before systems implementation. Prototyping reduces the risk of being in a situation whereby be no 
implementation is consistent with the specification and at the same time provides the desired functionality. 

9. Reduce unrealistic expectations among users. Heightened or unrealistic expectations can be a serious 
problem exacerbated by prototyping. Moreover due to the rapidity of prototyping, there is much less time to 
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recover from gaps in (he SRS. Contractor must insure that prototyping does not create unrealistic 
expectations among users. 

10. Insure that the SRS is understandable to the user. The user sees each process in a functional manner. 
The SRS should be compartmentalized in the same manner that the user views the system. For example, the 
user views travel as either a new travel request or as edit of an old travel request. To accomplish this, it is 
recommended that the SRS be more clearly sub-divided. 

11. Don’t use document delivery as a metric of project state. 

12. Need to map SRS to documents that are familiar to the user. In the case of travel, the sections of the 
SRS should refer to portions of the travel document in a generic way since the travel documents will likely 
change after implementation. 

13. The SRS should identify maintenance issues focusing on those events that stand a high probability of 
occurrence. 

14. Additionally, Mr. Forney asked me to examine the Systems Requirements Specification (SRS) for the 
Travel Function. The following represent a summary of my comments: 

14A Sped fi city . If the SRS is not detailed enough, then the design process will take much longer 
and will be much more iterative. It is important that the SRS contain the correct level of detail to avoid the 
"yo-yo" effect whereby the design is changed to reflect ever changing, amorphous or misunderstood 
requirements. Ideally the requirements document would enumerate the reports and discuss the contents and 
calculation of each field. 

14B. User Perspective . Document should have the user’s "looking-in" perspective. A key problem 
in fostering communication is to have a common terminology. One objective of the SRS is to establish a 
common terminology. 

14C. Functional and Non-Functional Requirements . The document must address both functional and 
non-functional boundaries and behaviors. These non-functional requirements are related to characteristics 
like security or project management that place boundaries on acceptable solutions. 

14D. Maintenance Sc Documentation . Maintenance must be planned and designed into the 
software. For example, the SRS should address such issues as the ability to add fields to the form, table or 



report? How is it done? If an signature is added to the travel document, how is it added? Maintenance 
consideration warrant a separate section. Ease of maintenance must include planned changes as well as 
repairs. Anticipated changes due to hardware evolution and changing user needs should to also be identified 
in the SRS. The maintenance of the code once it has been deployed will, in all likelihood, be by groups not 
originally involved in the design. Their training will be greatly enhanced if the requirements document can 
be used as a reference to design decisions and other controlling design documents. SRS should evolve to be 
a reference document. 

14E. Mapping . The user should be able to map each portion of the SRS to a form or document that 
he/she is now familiar with. As the SRS currently exists, the user would be unable to map the travel forms 
to the SRS. This would be very helpful to the user who is most familiar with the travel forms and tends to 
relate processes to the actual form. 

14F. Interface Requirements . For each interface, the following should be specified: a) Description 
of operational considerations of data transfer, such as security considerations. What protection is offered one 
part of system from corruption from another part? b) General description of data transfer requirements to 
and from the subject system and characteristics of communications media/systems used for the transfer. c)Type 
of anticipated interface, such as manual or automatic, d) Anticipated interface procedures, including 
telecommunications considerations. 

14G. Prototyping . User satisfaction is diminished by the passage of time between requirements 
generation and system delivery. Prototyping is very useful in allaying the dissatisfaction of users. Additionally 
prototyping can prove to be highly effective for early identification of specification faults. Nonetheless, the 
prototyping does not obviate the need for a detailed SRS. Moreover, with prototyping as part of the 
development or life cycle process, there is much less time to recover from gaps in the SRS.. Thus a non- 
detailed SRS becomes problematic. 

14H. Readability . Sequencing— so that the user is more able to understand the SRS, it would be 
very useful if the sequencing of processes were made more clear in the SRS. This could be done by sub- 
dividing the SRS into processes that are more understandable to the users and clearly dividing them. For 
example, the SRS could be color coded or tabbed. The current method of using the numbering scheme to 
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divide the SRS should be supplemented with more clear distinctions between sections. Page numbers could 
be used to more clearly divide the travel sections. It is recommended that a third digit be added to the page 
numbers to indicate divisions within the SRS. Printing on front and back of pages would also make the SRS 
less formidable. The addition of footnotes of relevant data dictionary items in the SRS would prove especially 
helpful in certain instances. 

141* Security Requirements . Are there not overall unique security requirements relevant to travel? 
For example, insuring travel funds are not channeled to other fund accounts. The ability of a large number 
of individuals to update central data stores (e.g. NPPS) could present problems. Some of the security 
measures should be brought out in the SRS. 

14J. Other Questions or Comments , a) will system maintain an edit history for certain accounts and 
certain fields? Can it track who updated certain important fields? b) Is foreign travel really a separate entity? 
As presented in SRS it appears to be almost identical to domestic travel. However, examining the travel 
forms, they are clearly not the same, c) The ability to change personnel information in the NPPS file at many 
junctures appears to open up potential integrity problems, d) When error messages are displayed, the SRS 
does not indicate what the user will do next. 
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